Method and System For Exception-Less System Calls In An Operating System

ABSTRACT

A method and system is disclosed which can enhance the performance of computer systems by altering the operation of the operating system of those computer systems. The invention provides a system and method for making exception-less system calls, decoupling the invocation and execution of system calls, thus avoiding or reducing the direct and indirect overheads associated with making a conventional exception-based system call. The invention can be employed with single core processor systems and with multi-core processor systems, both affording improved temporal execution locality and the later also providing improved spatial execution locality. The system and method can be employed in a wide range of operating systems.

RELATED APPLICATIONS

This application claims priority from U.S. provisional patentapplications Ser. Nos. 61/541,161 and 61/541,164, each filed Sep. 30,2011, and is a continuation of utility application Ser. No. 13/633,025and the contents of each of these provisional patent applications andthe utility application are included herein, in their entirety, byreference.

FIELD OF THE INVENTION

The present invention relates to a system and method for improving theperformance of computer operating systems. More specifically, thepresent invention relates to a system and method for providing andperforming exception-less system calls in a computer operating system.

BACKGROUND OF THE INVENTION

Most modern computers, and especially general-purpose computer systems,execute an operating system which manages the computer's resources andprovides a set of common services for application programs which are tobe executed on the computer. Operating systems typically act as anintermediary layer between application programs and the computerresources, providing and managing services such as memory allocation andinput and output (I/O) functions, such as reading and/or writinginformation to and from disc drives, or their equivalent.

Most operating systems employ a security model which features at leasttwo modes in which the computer can operate. In the first mode, oftenreferred to as “supervisor mode” or “kernel mode”, the operating systemhas unrestricted access to the hardware and other resources of thecomputer system. Generally, only the operating system itself (or thekernel portion of the operating system) executes in supervisor mode. Thesecond mode, often referred to as “protected mode” or “user mode” is themode in which user applications and less important operating systemcomponents execute and software being executed in user mode cannotdirectly access the resources of the computer system such as theabove-mentioned I/O and/or memory allocation functions.

Instead, when a user application requires access to I/O or othercomputer resources only available in kernel mode, the user applicationmakes a request for those resources to the operating system. Such arequest is typically referred to as a “system call” and the operatingsystem receives the system call and attempts to fulfill the request.

When the operating system needs to perform tasks which can only beperformed in kernel mode, the mode of the computer system must beswitched from user mode to kernel mode and, when the request has beenfulfilled, the mode must be switched back from kernel mode to user mode.These switches, often referred to as “mode switches” or “contextswitches”, are performed by the operating system executing a specialinstruction which results in a processor “exception” which allows thecomputer system to change from user mode to kernel mode where therequested system call can be processed and/or back again.

Operating systems which employ this security model have been inwidespread use for many years and are the presently preferred method ofimplementing general-purpose (and many special purpose) computersystems. However, problems exist with these systems. In particular,modern computer systems are typically now superscalar which means thatmore than one instruction can be executed by the processor in parallelin different parts of the processor. Superscalar systems typicallyinclude a set of features such as instruction pipelines, multi-leveldata and instruction caches, out of order and/or predictive executionunits, translation look aside buffers, etc. which assist in achievingsuperscalar performance.

Modern superscalar systems now commonly also have multiple processors(i.e.—cores“) further increasing the ability of the computer system toexecute multiple instructions in parallel. As used herein, the term“superscalar” is intended to comprise computer systems which can executemore than one instruction in parallel and includes both single core andmulti-core computer systems.

While superscalar computer systems provide significant advantages, theydo suffer from some problems. In particular, many of the superscalarfeatures of such systems require the executing program to displaylocality of execution to benefit from these features. Without localityof execution, features such as caches, predictive execution units, etc.cannot provide their advantages and the rate of instructions executedper cycle by a superscalar computer system will drop significantlywithout locality of execution.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide a novel system andmethod for providing and performing exception-less system calls in acomputer operating system which obviates or mitigates at least onedisadvantage of the prior art.

According to a first aspect of the present invention, there is provideda non-transitory computer readable medium having instructions storedthereon for a system of performing exception-less system calls on acomputer system executing an operating system having a user mode and akernel mode, the operating system executing at least one userapplication, comprising: instructions for creating a shared memory spacebetween the at least one user application executing in user mode and theoperating system executing in kernel mode; instructions for the userapplication to place a request for at least one system call into theshared memory space; instructions for the operating system, in kernelmode, to check the shared memory space from time to time to identifysystem calls requested by the at least one user application;instructions for the operating system to perform at least one identifiedsystem call for the at least one user application and to indicatecompletion of the at least one identified system call to the at leastone user application via the shared memory space; and instructions forthe at least one user application to check the shared memory space fromtime to time to determine when the at least one system call has beencompleted.

Preferably, the non-transitory computer readable medium further includesinstructions to have the operating system perform the at least onerequested system call on a temporally scheduled basis or, where thecomputer system includes at least two processor cores, further includinginstructions to have the operating system select at least one of the atleast two processor cores and to cause the system calls to bepreferentially performed on the selected at least one processor core.

According to another aspect of the present invention, there is provideda computer-implemented method of performing exception-less system callson a computer system executing an operating system having a user modeand a kernel mode, the operating system executing at least one userapplication, the method comprising the steps of: for each at least oneuser application, creating a shared memory space between the userapplication and the operating system; in the shared memory space of eachat least one user application, creating a system call entry for each ofat least one exception-less system call; instantiating a system callthread in the operating system kernel for each system call entry in eachshared memory space; allowing the at least one user application to setthe contents of the at least one system call entry to request theperformance of a system call by the operating system and to set thestatus of that system call entry appropriately; causing a system callthread executing in the kernel space of the operating system to checkthe status of at least one system call entry in the shared memory spaceto identify a requested exception-less system call waiting to beperformed and to execute the system call requested by that system callentry and to update the corresponding status of that system call entry;and causing the at least one user application to check the status of thesystem call entries in the shared memory space to determine when acorresponding exception-less system call has been completed.

The present invention teaches a method and system which can enhance theperformance of computer systems by altering the operation of theoperating system of those computer systems. The invention provides asystem and method for making exception-less system calls, thus avoidingor reducing the direct and indirect overheads associated with making anexception-based system call. In tests, significant improvements inoverall performance of a computer system have been achieved.

The present invention improves the performance of user applicationsexecuting on a computer system executing an operating system bydecoupling the execution of system calls from the invocation of systemcalls, thus improving execution locality within the computer system.

The invention can be employed with single core processor computersystems and with multi-core processor computer systems, both affordingimproved temporal execution locality and the later also providingimproved spatial execution locality. The system and method can beemployed in a wide range of operating systems.

Other features and advantages of the present invention are describedmore fully below.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the present invention will now be described, byway of example only, with reference to the attached Figures, wherein:

FIG. 1 shows a flowchart of the method of a user space process making anexception-less system call; and

FIGS. 2 a, 2 b and 2 c show a flowchart of the method of kernel spaceprocessing of exception-less system calls in one operating systemenvironment.

DETAILED DESCRIPTION OF THE INVENTION

The present inventors have determined that, during a context switchbetween user mode and kernel mode, or vice versa, the contents ofcaches, buffers, pipelines and other superscalar optimization featuresare “polluted” (i.e.—their contents and/or state invalidated) by thecontext switch as locality of execution is lost.

In tests, the present inventors have found that a significant drop inthe instruction per cycle (IPC) rate of a computer system occurs when asystem call is made. This drop is both due to the direct overheadassociated with saving the contents of system registers and performingthe context switch and to the indirect overhead associated with theresulting pollution of superscalar features. In fact, in tests by theinventors, it was found that the performance degradation from indirectoverhead was significantly larger than that resulting from the directoverhead.

Accordingly, to reduce the degradation of the performance of superscalarcomputer systems which results from context switches in prior artoperating systems, the present inventors have developed anexception-less system call system and method.

In conventional operating systems, a system call is made by writingnecessary values to appropriate system registers and having theprocessor execute a special instruction that results in a processorexception. The processor exception results in the user-mode instructionpipeline being flushed, the saving of a predefined set of registervalues onto the kernel stack, changing the processor domain from usermode to kernel mode and redirecting execution to the registeredexception handler. As part of this process, superscalar features likethe L1 data and instruction caches, translation look-aside buffers,branch prediction tables, prefetch buffers and larger unified caches(i.e.—L2 and L3) have user mode data overwritten with kernel mode dataand are thus polluted and execution locality is lost.

Returning from kernel mode, after the exception has been handled, theresults of the system call are written to defined registers, the saveduser mode register values are pulled from the stack and the domain isswitched from kernel mode to user mode.

The loss of execution locality which results from this process issignificant and, in tests conducted by the inventors, the IPC rate ofthe computer system upon return from a system call was significantlylower than the IPC rate prior to making the system call and manythousands of cycles were required to re-achieve the pre-system call IPCrate.

To reduce the loss of execution locality resulting from system calls,the present inventors have developed what they refer to as anexception-less system call. In fact, the present inventors havedeveloped two approaches to an exception-less system call: the firstbeing the batching of system calls; and the second, for multi-coresystems, being core specialization. As will be apparent, theexception-less system call of the present invention can employ either orboth of these approaches, as desired.

With the batching of system calls, the execution of one or more systemcalls is delayed and then those delayed system calls are subsequentlyexecuted as a batch. Thus, instead of performing a separate contextswitch for each system call, a context switch is only incurred once forthe set of system calls and this improves temporal locality ofexecution.

For multi-core systems, an exception-less system call can be scheduledfor execution on a core different from the core on which the system callwas invoked, thus providing improved spatial locality and reducingindirect overheads.

In a current embodiment of the present invention, the interface for theexception-less system call is one or more memory pages that are sharedbetween user and kernel spaces. These pages, referred to herein assyscall pages, are organized to contain exception-less system callentries, each entry containing space for the request status (i.e.“free”, “submitted”, “busy”, “cancel”, “done”, etc), a system callnumber, arguments and return values.

While the description herein employs the term “thread” when referring toexecuting processes within the computer system, it is intended that theterm “thread” not be a limitation to the scope of the invention and that“thread” should be read to also encompass other execution units(i.e.—processes, tasks, etc.) which are available in operating systemswith architectures and/or operating modalities that offer such executionunits either instead of, or in addition to, threads.

To make an exception-less system call, a user space thread locates afree entry in the syscall pages, by checking the value of the statusfield, and populates that free entry with the necessary and appropriatevalues required for the particular system call using regular storeinstructions. Once the syscall entry has been populated, the user spacethread marks the status of that entry to “submitted” and the user spacethread can then continue executing without interruption.

The user space thread then later checks the status of the exception-lesssystem call by reading the status information in the corresponding entryin the syscall pages until the status is “done”. When done, the userthread can appropriately process any return values and will mark thestatus of the entry in the syscall page as “free” to allow the entryspace to be reused. The user space thread can then continue itsexecution again.

As will be apparent, none of these operations (storing values in thesyscall pages or reading the results from the syscall pages) causes anexception to be raised, hence the term exception-less system call.

While the above-discussion refers to syscall pages, the presentinvention is not so limited and any shared memory space can be used withthe present invention to pass exception-less system call entries betweenuser mode and kernel mode, as will occur to those of skill in the art.

Unlike exception based system calls, an exception-less system call doesnot create an explicit notification to the kernel that a call has beenmade, nor is an execution stack provided. Instead, with the presentinvention a kernel thread, referred to herein as a “syscall thread”,executes in kernel mode for each process executing on the computersystem which employs exception-less system calls.

Syscall threads execute to, according to a schedule: identify and pullwaiting exception-less system call requests from the syscall pages orother shared memory structure; to appropriately execute those calls onbehalf of the requesting user-mode thread; to place any return values inthe corresponding syscall page entry; and to update appropriately itsstatus in the corresponding syscall page entry.

In a specific embodiment of the present invention implemented in Linuxand subject to the Linux thread blocking architecture/model, a syscallthread is created for each entry in the syscall, or other shared memory,for each process employing exception-less system calls. Despite creatingmultiple syscall threads, only one syscall thread is active per userapplication and core (in multi-core computer systems) at any given time.If the system call does not block, all execution is performed by the onesyscall thread while the remaining syscall threads sleep on a workqueue. However, if the execution of the requested exception-less systemcall is blocked (by resource contention, etc.), immediately before thesyscall thread is put to sleep, the next syscall thread on the workqueue is awoken and starts executing the next system call. When theresources required by the first syscall thread (now sleeping) becomefree, it is awakened and resumes its execution.

Suitable modifications and alternatives to this blocking mechanism willbe apparent to those of skill in the art and, depending upon thearchitecture and models employed by the target operating system, mayvary significantly from that described above for the Linux model.

As should now be apparent, a great deal of flexibility is available inscheduling the execution of system calls by syscall threads. Asmentioned above, syscall threads can be scheduled to execute on one ormore selected cores in a multi-core system, typically the selected coreis different from the core on which the requesting user thread isexecuting, to improve spatial locality. Similarly, syscall threads canbe scheduled to execute at a variety of times and/or after specifiedevents, including at: pre-selected time intervals; or when user spacethreads are unable to make further progress without execution of waitingsystems calls; or combinations of these intervals and timings; etc.

As will be apparent, if desired these scheduling methods can be combinedto improve both temporal and spatial execution locality.

In a present single core embodiment of the present invention on theLinux system (kernel version 2.6.33), if no blocking occurs, theexecuting syscall thread processes all system calls, in sequence beforeswitching back to user mode. If a system call is blocked, the executingsyscall thread awakens another syscall thread which will beginprocessing the remaining system calls awaiting processing, againexecuting all remaining non blocked system calls, or if blocked,awakening another syscall thread, etc. All pending system calls areeither finished, or blocked, with at least one system call having beencompleted, before the computer system is returned to user mode.

In a present multi-core embodiment of the present invention on the Linuxsystem, the execution of syscall threads is biased to a subset of theavailable cores, the subset either being dynamically specified inaccordance with the workload of the computer system or, in a simplercase, being statically defined. Execution of syscall threads ispreferentially assigned to one of the subset of cores which is notpresently executing a syscall thread to enhance spatial executionlocality.

As should be apparent to those of skill in the art, the implementationof exception-less system calls in accordance with the present inventioncan be achieved in addition to prior art exception-based system callmechanisms. In fact, it is contemplated that such a coexistence ofsystem call mechanisms will be the norm as start up and initializationof many computer operating systems will require exception-based systemcalls. Further, avoiding the pollution of superscalar features by somesystem calls will not be of concern.

FIG. 1 shows a flowchart explaining the method of a user space processmaking an exception-less system call. The method starts at step 100wherein a shared memory space, such as the above-described syscallpages, is created for the process executing in user mode space. Thecreation of this shared memory space can be achieved in a wide varietyof manners, as will occur to those of skill in the art, and will dependupon the particular operating system on which the present invention isimplemented. The shared memory space can be proactively created at thetime of creation of the process, or can be subsequently created thefirst time the process wishes to make an exception-less system call.

At step 104, a set of entries of data structures necessary for making anexception-less system call and providing return values is created in theshare memory space and each of these entries includes a status fieldwhich is initialized to indicate that the entry is free.

When a thread in the user mode process needs to make an exception-lesssystem call, the thread locates an entry in the shared memory spacewhose status is indicated as being “free”, as shown at step 108.

Next, at step 112 the thread writes the relevant data required to makethe desired system call into the entry identified at step 108 andchanges the status of that entry to “submitted”.

The thread can then continue execution but also checks, from time totime, the status of the entry as indicated at step 116. When the statusof the entry is “done”, as indicated at step 120, the method continuesto step 124 wherein the thread processes any return values from theexception-less system call and makes the entry in the shared memory asagain being free and then the thread continues its execution.

FIGS. 2 a, 2 b and 2 c show a flowchart explaining the method of kernelspace processing of exception-less system calls in a Linux operatingsystem environment or other environment having a similar thread blockingarchitecture.

The method commences at step 200 where the operating system creates ashared memory space for a process executing in user mode. As will beapparent, this step corresponds to, and is the same as, step 100 inFIG. 1. Next, at step 204, a set of entries of data structures necessaryfor making an exception-less system call and providing return values iscreated in the share memory space and each of these entries includes astatus field which is initialized to indicate that the entry is “free”.This step corresponds to, and is the same as, step 104 in FIG. 1.

Next, at step 208, a syscall thread, or other suitable execution unit,is created in the operating system kernel space for each entry createdin step 204 in the shared memory space. As discussed above, the creationof this multiplicity of syscall threads is desired when dealing with theLinux thread blocking architecture and may not be desired or requiredunder other operating systems and the present invention is not limitedto use with such a thread blocking architecture.

At step 212, a syscall thread checks the entries in the shared memory tolocate an entry with a status of “submitted” and commences processing ofthe system call requested in that entry, updating its status to “busy”.

At step 216, the syscall thread determines if processing of therequested system call is blocked and, if it is, the method continues atstep 218.

At step 218, another syscall thread is started by the blocked syscallthread which his then put to sleep. The newly started syscall threadchecks for entries in the shared memory space with a status of“submitted” and begins processing the entry. The method then returns tostep 216.

If at step 216, the processing of the requested system call is notblocked, the method continues at step 22 where processing of therequested system call is completed. The syscall thread writes any returnvalues from the system call to the corresponding entry in the sharedmemory and marks the status of that entry as “completed”.

At step 226 the method checks to see if any previously blocked syscallthread is no longer blocked. If such an unblocked thread exists, themethod proceeds to step 230 wherein execution of that thread isrecommenced and the method returns to step 222.

If, at step 226, no previously block syscall thread exists, or any suchblocked syscall thread remains blocked, processing returns to step 212.

As will be apparent, the method of FIGS. 2 a, 2 b and 2 c can be easilymodified by those of skill in the art for operating systems withresource contention architectures which differ from the Linux threadblocking architecture described herein.

As will also be apparent, the method of FIGS. 2 a, 2 b and 2 c does notexplicitly show the scheduling of syscall threads. As discussed above, avariety of scheduling approaches can be employed with the presentinvention including those which enhance temporal execution locality and,in multi-core computer systems, those which enhance spatial executionlocality.

As should now be apparent, the present invention provides a method andsystem which can enhance the performance of computer systems by alteringthe operation of the operating system of those computer systems. Theinvention provides a system and method for making exception-less systemcalls, thus avoiding or reducing the direct and indirect overheadsassociated with making an exception-based system call. In testenvironments, significant improvements in overall performance of acomputer system have been achieved.

The present invention improves the performance of user applicationsexecuting on a computer system executing an operating system bydecoupling the execution of system calls from the invocation of systemcalls, thus improving execution locality within the computer system.

The invention can be employed with single core processor computersystems and with multi-core processor computer systems, both affordingimproved temporal execution locality and the later also providingimproved spatial execution locality. The system and method can beemployed in a wide range of operating systems.

The above-described embodiments of the invention are intended to beexamples of the present invention and alterations and modifications maybe effected thereto, by those of skill in the art, without departingfrom the scope of the invention which is defined solely by the claimsappended hereto.

We claim:
 1. A non-transitory computer readable medium havinginstructions stored thereon for a system of performing exception-lesssystem calls on a computer system executing an operating system having auser mode and a kernel mode, the operating system executing at least oneuser application, comprising: instructions for creating a shared memoryspace between the at least one user application executing in user modeand the operating system executing in kernel mode; instructions for theuser application to place a request for at least one system call intothe shared memory space; instructions for the operating system, inkernel mode, to check the shared memory space from time to time toidentify system calls requested by the at least one user application;instructions for the operating system to perform at least one identifiedsystem call for the at least one user application and to indicatecompletion of the at least one identified system call to the at leastone user application via the shared memory space; and instructions forthe at least one user application to check the shared memory space fromtime to time to determine when the at least one system call has beencompleted.
 2. The non-transitory computer readable medium of claim 1further including instructions to have the operating system perform theat least one requested system call on a temporally scheduled basis. 3.The non-transitory computer readable medium of claim 1 wherein thecomputer system includes at least two processor cores and furtherincluding instructions to have the operating system select at least oneof the at least two processor cores and to cause the system calls to bepreferentially performed on the selected at least one processor core. 4.The non-transitory computer readable medium of claim 1 wherein theinstructions for the operating system cause a system call threadexecuting in the kernel mode of the operating system to check the statusof at least one system call entry in the shared memory space to identifythe at least one requested exception-less system call waiting to beperformed and to execute the system call requested by the identified atleast one exception-less system call entry.
 5. A computer-implementedmethod of performing exception-less system calls on a computer systemexecuting an operating system having a user mode and a kernel mode, theoperating system executing at least one user application, the methodcomprising the steps of: creating a shared memory space between the userapplication and the operating system for each at least one userapplication; in the shared memory space of each at least one userapplication, creating a system call entry for each of at least oneexception-less system call; instantiating a system call thread in theoperating system kernel for each system call entry in each shared memoryspace; allowing the at least one user application to set the contents ofthe at least one system call entry to request the performance of asystem call by the operating system and to set the status of that systemcall entry appropriately; causing a system call thread executing in thekernel space of the operating system to check the status of at least onesystem call entry in the shared memory space to identify a requestedexception-less system call waiting to be performed and to execute thesystem call requested by that system call entry and to update thecorresponding status of that system call entry; and causing the at leastone user application to check the status of the system call entries inthe shared memory space to determine when a corresponding exception-lesssystem call has been completed.